Reactの`experimental_useFormStatus`でフォーム検証をマスターする

フォームはウェブインタラクションの基盤です。シンプルなニュースレターの登録から複雑な多段階の金融アプリケーションまで、ユーザーがアプリケーションと通信するための主要なチャネルです。しかし、長年にわたり、Reactでのフォーム状態の管理は、複雑さ、ボイラープレート、依存関係の疲労の原因となってきました。私たちは、制御されたコンポーネントをやりくりし、状態管理ライブラリと格闘し、数え切れないほどの`onChange`ハンドラーを記述し、すべてシームレスで直感的なユーザーエクスペリエンスを追求してきました。

Reactチームは、ウェブ開発のこの基本的な側面を再考し、React Server Actionsを中心とした新しい強力なパラダイムの導入につながりました。この新しいモデルは、プログレッシブエンハンスメントの原則に基づいて構築されており、ロジックを本来あるべき場所、つまり多くの場合サーバーに近づけることで、フォーム処理を簡素化することを目的としています。このクライアント側の革命の中心にあるのは、2つの新しい実験的なフック、`useFormState`と、今日の議論の主役である`experimental_useFormStatus`です。

この包括的なガイドでは、`experimental_useFormStatus`フックを深く掘り下げていきます。その構文を見るだけでなく、それが可能にするメンタルモデル、つまりステータスベースの検証ロジックを探求します。このフックがUIをフォーム状態から分離し、保留状態の管理を簡素化し、サーバーアクションと連携して、JavaScriptがロードされる前でも機能する堅牢でアクセス可能、かつ非常に高性能なフォームを作成する方法を学びます。Reactでフォームを構築することについて知っていると思っていたすべてのことを再考する準備をしてください。

パラダイムシフト: Reactフォームの進化

`useFormStatus`がもたらす革新性を十分に理解するには、まずReactエコシステムにおけるフォーム管理の道のりを理解する必要があります。この文脈は、この新しいアプローチがエレガントに解決する問題を浮き彫りにします。

旧体制: 制御されたコンポーネントとサードパーティライブラリ

長年にわたり、Reactにおけるフォームへの標準的なアプローチは、制御されたコンポーネントパターンでした。これには以下が含まれます:

• 各フォーム入力の値を保持するために、React状態変数（例: `useState`から）を使用します。
• すべてのキーストロークで状態を更新する`onChange`ハンドラーを記述します。
• 状態変数を入力の`value`プロップに渡します。

これにより、Reactはフォームの状態を完全に制御できますが、かなりのボイラープレートが導入されます。10個のフィールドを持つフォームの場合、10個の状態変数と10個のハンドラー関数が必要になる場合があります。検証、エラー状態、および送信ステータスを管理すると、さらに複雑さが増し、多くの場合、開発者は複雑なカスタムフックを作成したり、包括的なサードパーティライブラリを探したりすることになります。

FormikやReact Hook Formなどのライブラリは、この複雑さを抽象化することで注目を集めました。これらは、状態管理、検証、およびパフォーマンスの最適化のための優れたソリューションを提供します。ただし、これらは管理する別の依存関係を表しており、多くの場合、クライアント側でのみ動作するため、フロントエンドとバックエンド間で検証ロジックが重複する可能性があります。

新時代: プログレッシブエンハンスメントとサーバーアクション

React Server Actionsは、パラダイムシフトをもたらします。中心となる考え方は、ウェブプラットフォームの基盤である標準のHTML `

`要素に基づいて構築することです。サーバーアクションを持つフォームは、従来のHTMLフォームの送信のように機能します。JavaScriptが失敗したり無効になったりした場合でも、完全に機能します。これがプログレッシブエンハンスメントの本質です。

JavaScriptがロードされると、Reactはフォームの送信プロセスをハイジャックし、ページ全体の再読み込みを防ぎ、サーバーアクションを非同期的に実行します。これにより、サーバーレンダリングされたアプリケーションの回復力と、シングルページアプリケーション（SPA）のリッチでインタラクティブなエクスペリエンスという、両方の長所が得られます。

このモデルは、ビジネスロジックと検証の真実の源をサーバー（またはサーバーのような環境）に戻します。クライアント側のコードは、主にそのサーバー通信の*ステータス*に基づいてUIをレンダリングすることに重点を置いて、よりシンプルになります。これはまさに`useFormStatus`が活躍する場所です。

内部構造: `experimental_useFormStatus`とは？

`experimental_useFormStatus`フックは、親の``要素の最後の送信に関する情報を提供するように設計されたクライアント側のツールです。これは、コンポーネントに、プロップを渡す必要なく、フォームの送信ステータスについて知る必要のあるすべてのことを伝える読み取り専用のフックです。

コア機能

大きなフォームの中にある送信ボタンを想像してみてください。このボタンは、フォームがいつ送信されているかをどのように知るのでしょうか？従来、`isSubmitting`のような状態変数を複数のコンポーネントのレイヤー（プロップドリリング）を介して渡す必要がありました。`useFormStatus`を使用すると、ボタンコンポーネントは、この情報を自分で見つけることができます。

フックは、``要素内にレンダリングされるコンポーネントから呼び出す必要があります。次に、その特定のフォームのライフサイクルに関するステータス情報を提供します。

`useFormStatus`フックの構造

`const status = useFormStatus()`を呼び出すと、次のキープロパティを持つオブジェクトが返されます:

• `pending` (boolean): これは最も頻繁に使用されるプロパティです。親フォームが現在送信されている場合は`true`、それ以外の場合は`false`です。ボタンを無効にしたり、ローディングスピナーを表示したり、保留中の状態をスタイルしたりするのに最適です。
• `data` (FormData): `FormData`インターフェイスを実装するオブジェクト。フォームで送信されたデータが含まれています。これは、楽観的なUIアップデートを実装するのに非常に役立ちます。たとえば、サーバーが作成を確認する前でも、ユーザーが送信した直後にリストにユーザーのコメントを表示するなどです。
• `method` (string): フォーム送信に使用されるHTTPメソッド（'get'または'post'）。
• `action` (function): 送信中に呼び出されたサーバーアクション関数への参照。

黄金律: ``の子

覚えておくべき重要なルールは、`useFormStatus`を使用するコンポーネントは、追跡している``要素の子としてレンダリングする必要があるということです。フォームのコンテキストにアクセスする必要があるため、``タグ自体をレンダリングする同じコンポーネントに含めることはできません。このため、`useFormStatus`ロジックを格納するために、``のようなコンポーネントが個別に作成されることがほとんどです。

簡単な例: スマート送信ボタン

最も一般的なユースケースを見てみましょう。標準の``の代わりに、フォームの送信状態を認識するコンポーネントを作成します。

ファイル: SubmitButton.js

import { experimental_useFormStatus as useFormStatus } from 'react-dom'; export function SubmitButton() { const { pending } = useFormStatus(); return (

{pending ? 'Submitting...' : 'Sign Up'} ); }

ファイル: SignUpForm.js

import { SubmitButton } from './SubmitButton'; import { signUpAction } from './actions'; // A server action export function SignUpForm() { return ( Email:
); }

この例では、`SubmitButton`は完全に自己完結型です。プロップを受け取りません。`useFormStatus`を使用して、`SignUpForm`がいつ保留中であるかを知り、自動的に自分自身を無効にし、テキストを変更します。これは、分離を行い、再利用可能なフォーム対応コンポーネントを作成するための強力なパターンです。

本質: ステータスベースの検証ロジック

ここで、コアコンセプトに到達します。`useFormStatus`は、単にローディング状態のためだけのものではありません。検証に関する異なる考え方を実現するための重要な要素です。

「ステータス検証」の定義

ステータスベースの検証は、検証フィードバックが主にフォーム送信の試行に応じてユーザーに配信されるパターンです。すべてのキーストローク（`onChange`）またはユーザーがフィールドを離れるとき（`onBlur`）に検証する代わりに、主要な検証ロジックはユーザーがフォームを送信するときに実行されます。この送信の結果（その*ステータス*、例: 成功、検証エラー、サーバーエラー）は、UIを更新するために使用されます。

このアプローチは、React Server Actionsと完全に一致します。サーバーアクションは、検証の単一の真実の源になります。フォームデータを受け取り、ビジネスルール（例: 「このメールアドレスはすでに使用されていますか？」）に対して検証し、結果を示す構造化された状態オブジェクトを返します。

パートナーの役割: `experimental_useFormState`

`useFormStatus`は何が起こっているか（保留中）を教えてくれますが、何が起こったかの*結果*は教えてくれません。そのためには、兄弟フックである`experimental_useFormState`が必要です。

`useFormState`は、フォームアクションの結果に基づいて状態を更新するように設計されたフックです。アクション関数と初期状態を引数として受け取り、新しい状態とフォームに渡すラップされたアクション関数を返します。

const [state, formAction] = useFormState(myAction, initialState);

• `state`: これには、`myAction`の最後の実行からの戻り値が含まれます。ここにエラーメッセージが表示されます。
• `formAction`: これは、`
  `の`action`プロップに渡す必要のあるアクションの新しいバージョンです。これが呼び出されると、元のアクションがトリガーされ、`state`が更新されます。

組み合わせたワークフロー: クリックからフィードバックまで

`useFormState`と`useFormStatus`が連携して完全な検証ループを作成する方法を次に示します:

1. 初期レンダリング: フォームは、`useFormState`によって提供される初期状態でレンダリングされます。エラーは表示されません。
2. ユーザー送信: ユーザーが送信ボタンをクリックします。
3. 保留中の状態: 送信ボタンの`useFormStatus`フックは、すぐに`pending: true`を報告します。ボタンが無効になり、ローディングメッセージが表示されます。
4. アクションの実行: サーバーアクション（`useFormState`によってラップ）は、フォームデータとともに実行されます。検証を実行します。
5. アクションの戻り: アクションが検証に失敗し、状態オブジェクトを返します。例:
   `{ message: "Validation failed", errors: { email: "This email is already taken." } }`
6. 状態の更新: `useFormState`はこの戻り値を受け取り、`state`変数を更新します。これにより、フォームコンポーネントの再レンダリングがトリガーされます。
7. UIフィードバック: フォームが再レンダリングされます。`useFormStatus`からの`pending`ステータスは`false`になります。コンポーネントは、`state.errors.email`を読み取り、メール入力フィールドの横にエラーメッセージを表示できます。

このフロー全体は、送信ステータスと結果によって完全に駆動される、明確でサーバーによる信頼できるフィードバックをユーザーに提供します。

実践的なマスタークラス: 複数フィールドの登録フォームの構築

完全な本番スタイルの登録フォームを構築することで、これらの概念を具体化しましょう。検証にはサーバーアクションを使用し、`useFormState`と`useFormStatus`の両方を使用して、優れたユーザーエクスペリエンスを作成します。

ステップ1: 検証を使用したサーバーアクションの定義

まず、サーバーアクションが必要です。堅牢な検証のために、一般的なライブラリであるZodを使用します。このアクションは、Next.jsのようなフレームワークを使用している場合は、`'use server';`ディレクティブでマークされた別のファイルに存在します。

ファイル: actions/authActions.js

'use server'; import { z } from 'zod'; // Define the validation schema const registerSchema = z.object({ username: z.string().min(3, 'Username must be at least 3 characters long.'), email: z.string().email('Please enter a valid email address.'), password: z.string().min(8, 'Password must be at least 8 characters long.'), }); // Define the initial state for our form export const initialState = { message: '', errors: {}, }; export async function registerUser(prevState, formData) { // 1. Validate the form data const validatedFields = registerSchema.safeParse( Object.fromEntries(formData.entries()) ); // 2. If validation fails, return the errors if (!validatedFields.success) { return { message: 'Validation failed. Please check the fields.', errors: validatedFields.error.flatten().fieldErrors, }; } // 3. (Simulate) Check if user already exists in the database // In a real app, you would query your database here. if (validatedFields.data.email === 'user@example.com') { return { message: 'Registration failed.', errors: { email: ['This email is already registered.'] }, }; } // 4. (Simulate) Create the user console.log('Creating user:', validatedFields.data); // 5. Return a success state // In a real app, you might redirect here using `redirect()` from 'next/navigation' return { message: 'User registered successfully!', errors: {}, }; }

このサーバーアクションは、フォームの頭脳です。自己完結型で安全であり、成功状態とエラー状態の両方に対して明確なデータ構造を提供します。

ステップ2: 再利用可能なステータス対応コンポーネントの構築

メインのフォームコンポーネントをクリーンに保つために、入力と送信ボタン専用のコンポーネントを作成します。

ファイル: components/SubmitButton.js

'use client'; import { experimental_useFormStatus as useFormStatus } from 'react-dom'; export function SubmitButton({ label }) { const { pending } = useFormStatus(); return ( {pending ? 'Processing...' : label} ); }

`aria-disabled={pending}`の使用に注意してください。これは重要なアクセシビリティの実践であり、スクリーンリーダーがdisabled状態を正しくアナウンスすることを保証します。

ステップ3: `useFormState`を使用したメインフォームの組み立て

次に、メインフォームコンポーネントにすべてをまとめましょう。`useFormState`を使用して、UIを`registerUser`アクションに接続します。

ファイル: components/RegistrationForm.js

'use client'; import { experimental_useFormState as useFormState } from 'react-dom'; import { registerUser, initialState } from '../actions/authActions'; import { SubmitButton } from './SubmitButton'; export function RegistrationForm() { const [state, formAction] = useFormState(registerUser, initialState); return (

Register

{state?.message && !state.errors &&

{state.message}

} {state?.message && state.errors &&

{state.message}

}

Username {state?.errors?.username && (

{state.errors.username[0]}

)}

Email {state?.errors?.email && (

{state.errors.email[0]}

)}

Password {state?.errors?.password && (

{state.errors.password[0]}

)}

); }

このコンポーネントは宣言型でクリーンになりました。`useFormState`によって提供される`state`オブジェクトを除いて、状態を管理しません。その唯一の仕事は、その状態に基づいてUIをレンダリングすることです。ボタンを無効にするロジックは`SubmitButton`にカプセル化され、すべての検証ロジックは`authActions.js`に存在します。この関心の分離は、保守性にとって非常に有利です。

高度なテクニックとプロフェッショナルなベストプラクティス

基本的なパターンは強力ですが、実際のアプリケーションではより多くのニュアンスが必要になることがよくあります。いくつかの高度なテクニックを探求しましょう。

ハイブリッドアプローチ: インスタント検証と送信後検証のマージ

ステータスベースの検証は、サーバー側のチェックに最適ですが、ユーザーにメールアドレスが無効であることを伝えるためにネットワークラウンドトリップを待つと、遅くなる可能性があります。ハイブリッドアプローチが最適な場合がよくあります:

• HTML5検証の使用: 基本を忘れないでください！`required`、`type="email"`、`minLength`、`pattern`などの属性は、コストなしでインスタントのブラウザネイティブフィードバックを提供します。
• 軽量のクライアント側検証: 純粋に美容的またはフォーマットチェック（例: パスワード強度インジケーター）のために、最小限の`useState`と`onChange`ハンドラーを引き続き使用できます。
• サーバー側の権限: クライアント側では実行できない最も重要なビジネスロジック検証のために、サーバーアクションを予約します（例: 一意のユーザー名のチェック、データベースレコードに対する検証）。

これにより、単純なエラーに対する即時フィードバックと、複雑なルールに対する信頼できる検証という、両方の長所が得られます。

アクセシビリティ (A11y): すべての人のためのフォームの構築

アクセシビリティは交渉の余地がありません。ステータスベースの検証を実装する場合は、次の点を念頭に置いてください:

• エラーのアナウンス: 例では、エラーメッセージコンテナーで`aria-live="polite"`を使用しました。これにより、スクリーンリーダーは、ユーザーの現在のフローを中断することなく、エラーメッセージが表示されるとすぐにアナウンスするように指示されます。
• エラーの入力を関連付けます: より堅牢な接続のために、`aria-describedby`属性を使用します。入力は、そのエラーメッセージコンテナーのIDを指し、プログラムによるリンクを作成できます。
• フォーカスの管理: エラーのある送信の後、最初の無効なフィールドにプログラムでフォーカスを移動することを検討してください。これにより、ユーザーは何が間違っていたのかを検索する必要がなくなります。

`useFormStatus`の`data`プロパティを使用した楽観的なUI

ユーザーがコメントを投稿するソーシャルメディアアプリを想像してみてください。1秒間スピナーを表示する代わりに、アプリを瞬時に感じさせることができます。`useFormStatus`の`data`プロパティはこれに最適です。

フォームが送信されると、`pending`がtrueになり、`data`に送信の`FormData`が入力されます。この`data`を使用して、一時的な「保留中」の視覚状態ですぐに新しいコメントをレンダリングできます。サーバーアクションが成功すると、保留中のコメントをサーバーからの最終データに置き換えます。失敗した場合は、保留中のコメントを削除してエラーを表示できます。これにより、アプリケーションは非常に応答性が高くなります。

「実験的」な海域のナビゲート

`experimental_useFormStatus`および`experimental_useFormState`の「experimental」プレフィックスに対処することが重要です。

「実験的」が実際に意味すること

ReactがAPIを実験的とラベル付けする場合、それは次のことを意味します:

• APIが変更される可能性があります: 名前、引数、または戻り値は、破壊的な変更のための標準的なセマンティックバージョニング（SemVer）に従わずに、将来のReactリリースで変更される可能性があります。
• バグがある可能性があります: 新しい機能として、まだ完全に理解または解決されていないエッジケースがある可能性があります。
• ドキュメントがまばらである可能性があります: コアコンセプトは文書化されていますが、高度なパターンに関する詳細なガイドはまだ進化している可能性があります。

いつ採用し、いつ待つか

では、プロジェクトで使用する必要がありますか？答えはコンテキストによって異なります:

• 推奨: 個人的なプロジェクト、内部ツール、スタートアップ、または潜在的なAPIの変更の管理に慣れているチーム。これらの機能をApp Routerに統合したNext.jsのようなフレームワーク内で使用することは、フレームワークが一部のチャーンを抽象化するのに役立つため、一般的に安全な賭けです。
• 注意して使用してください: 大規模なエンタープライズアプリケーション、ミッションクリティカルなシステム、またはAPIの安定性が最も重要な長期メンテナンス契約のあるプロジェクト。これらの場合、フックが安定したAPIに昇格するまで待つのが賢明かもしれません。

これらのフックの安定化に関する発表については、公式のReactブログとドキュメントに常に注意してください。

結論: Reactにおけるフォームの未来

`experimental_useFormStatus`および関連するAPIの導入は、単なる新しいツールではありません。これは、Reactでインタラクティブなエクスペリエンスを構築する方法における哲学的な変化を表しています。ウェブプラットフォームの基盤を受け入れ、ステートフルロジックをサーバー上に共同配置することで、よりシンプルで、より回復力があり、多くの場合、よりパフォーマンスの高いアプリケーションを構築できます。

`useFormStatus`が、コンポーネントがフォーム送信のライフサイクルに反応するためのクリーンで分離された方法をどのように提供するかを見てきました。保留中の状態に対するプロップドリリングを排除し、スマート`SubmitButton`のようなエレガントで自己完結型のUIコンポーネントを可能にします。`useFormState`と組み合わせると、ステータスベースの検証という強力なパターンがアンロックされます。このパターンでは、サーバーが究極の権限であり、クライアントの主な責任は、サーバーアクションによって返される状態をレンダリングすることです。

「実験的」タグはある程度の注意を必要としますが、方向性は明確です。Reactにおけるフォームの未来は、プログレッシブエンハンスメント、簡素化された状態管理、およびクライアントロジックとサーバーロジック間の強力でシームレスな統合の1つです。今日これらの新しいフックをマスターすることで、新しいAPIを学ぶだけでなく、Reactを使用した次世代のウェブアプリケーション開発に備えています。